Кто-нибудь возражал бы взглянуть на мою структуру XML?

Question

Я относительно новичок в этом, но я надеялся, что кто-нибудь может предложить хорошую критику этой XML-структуры, которую я собрал. Я не ищу ничего в глубине, но скорее, если кто-то заметит что-то изначально неправильное в структуре (или какие-либо советы, чтобы сделать это лучше), я был бы очень благодарен

У нас есть большое количество продуктов, которые мы продаем оптом, и наши клиенты искали источник данных для включения наших продуктов в свои веб-сайты.

<product modified="">
    <id></id>
    <title></title>
    <description></description>
    <upc></upc>
    <quantity></quantity>
    <images>
        <image width="" height=""></image>
        <image width="" height=""></image>
        <image width="" height=""></image>
    </images>
    <category>
        <name></name>
        <subcategory></subcategory>
    </category>     
    <sale expiration="">yes</sale>
    <msrp></msrp>               
    <cube></cube>
    <weight></weight>
    <pricing>
        <tier>
            <pack><pack>
            <price></price>
        </tier>
        <tier>
            <pack><pack>
            <price></price>
        </tier>         
        <tier>
            <pack><pack>
            <price></price>
        </tier>
    </pricing>
</product>

Мы продаем в 3 разных размерах упаковки, поэтому цена узла.

Answer 1

1. Мне не ясно, что вы последовательно используете дочерние элементы для обозначения отношений «один ко многим». Если у продукта может быть несколько категорий, тогда хорошо, но если у него может быть только одна категория, вам лучше использовать отдельные элементы с именами categoryName и categorySubcategory. В противном случае кто-то где-то неправильно поймет семантику вашего XML, и у вас возникнет проблема, которую можно устранить, если бы вы были последовательны.

2. Говоря об этом, вы должны иметь в виду план того, что происходит, когда вам нужно использовать несколько слов в именах тегов.

3. Мне не ясно, что у вас есть постоянная причина использовать атрибуты против элементов. Я подозреваю, что вы дали атрибуты image elements width и height, потому что именно так они представлены в HTML. Я бы только копировал соглашения HTML, если бы использовал их во всем своем дизайне. Я понятия не имею, почему элемент sale имеет атрибут expiration.

4. Говоря об этом элементе sale, представляйте логические значения, используя строки true и false. (Вы также можете использовать 1 и 0.) Более широкий вопрос: используйте представления XML-схемы для типизированных данных.

Согласованность в дизайне XML в 100 раз ценнее читабельности. Если у вас есть согласованный XML, вы можете легко преобразовать его в читаемые формы; обратное не так.

Answer 2

Если вы переместите все атрибуты (т. Е. / modified, width, height и expiration) в элементы, то клиенты могут автоматически сопоставить спецификацию вашего продукта 1: 1 с JSON или их внутренним объектом. Фактически, в один прекрасный день вы можете рассмотреть возможность предоставления JSON или буферов протокола в качестве альтернативного формата для ваших данных, а простая структура XML позволит автоматически выполнять преобразование. Облегчение, если у вас есть десятки различных форматов XML (которые могут время от времени меняться). Очень редко люди читают XML и извлекают из него информацию вручную, поэтому совершенно не нужно ставить красоту XML на первое место.

Answer 3

Я думаю, <pack> и <price> могут быть атрибутами <tier>, или предпочтительно просто удалить <tier> и иметь <pack> и <price> в качестве атрибутов <pricing>;

<tier pack="some-pack" price="some-price" />

или

<pricing pack="big-pack" price="high-price" />

Не совсем уверен, имеет ли это смысл для вас (или для вашего бизнеса), но немного очистит XML.